POV-Ray : Newsgroups : povray.programming : POV-Ray parser in Java : Re: POV-Ray parser in Java Server Time
21 Jul 2024 04:22:11 EDT (-0400)
  Re: POV-Ray parser in Java  
From: Vadim Sytnikov
Date: 9 Jan 2003 01:48:16
Message: <3e1d1b30@news.povray.org>
"Thorsten" <nomail@nomail> wrote:
> No, he implied that POV-Ray is missing a fast parser in the part I quoted.

Correct.

> Regarding a grammar: Grammars in a format assuming a specific parser
> generator are hardly very useful. And formal grammars cannot be directly
> read by any parser generator.

Now it is I that have to say that your statement is too bold without trying
to express POV-Ray's grammar in yacc. Did you do that? I have to admit that
I did not do that either, but my great experience in the area of compilers'
construction suggests that POV's *formal* grammar might as well turn out to
be the *working* one. Here, I imply nothing about its performance, just more
or less "direct use". But -- see below.

Yacc's/Bison's grammar is as close to BNF as it could probably be. So, if I
got you right, you implied that before a grammar could be made unambiguous
it would have to be transformed (in an attempt to resolve reduce-reduce
conflicts; shift-reduce are generally OK; here, I imply bottom-up analysis,
of course) to such a degree that it would become virtually unusable for a
human reader (e.g. one of those creating third-party SW to use with POV)?

I disagree. My point is that (i) POV-Ray's SDL structure is very linear, and
(ii) the number of reserved words it currently has suggests that performance
gain from using an FSM-based *scanner* would be even greater than the
languages with far fewer nmbers of keywords enjoy (e.g. C/C++).

The golden mean between your and my approaches would probably to make an
FSM-based POV SDL scanner (which *would* make difefrence, I swear) but leave
parser intact.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.